À voir #972 (comment) ?

Nous sommes sur une question de typographie. Donc, ce qui compte c'est le résultat une fois rendu dans le format final de lecture.
padpo utilise rst2txt qui maintient les doubles espaces, ce qui fait que Grammalecte génère une erreur (pas un avertissement).
rst2html conserve également les doubles espaces dans la sortie HTML, mais ceux-ci sont ensuite ignorés par le rendu HTML (conformément à la norme).
Enfin, la détection des « espaces surnuméraires » est une option de Grammalecte (et de grammalecte-cli).
En conclusion et comme je considère que le format final important est HTML, je propose de désactiver l'option « espaces surnuméraires » de Grammalecte et de ne pas corriger les doubles-espaces déjà présent.

@christopheNan Les doubles espaces remontés par Grammalecte sont ignorés par padpo, mais un autre checker de padpo (plus ancien) détecte les doubles espaces directement dans le RST (https://github.com/vpoulailleau/padpo/blob/master/padpo/checkers/doublespace.py). Celui-ci peut être supprimé, dès que le consensus est atteint.

J'aimais bien le commentaire de @awecx (#972 (comment)), et padpo ne signale, sur analyse d'une pull request, que les messages concernant les items modifiés, ce qui est en phase avec le commentaire mentionné.

De mon côté, je suis d'accord avec @christopheNan que le plus important est le rendu final de lecture qui doit être « parfait ». Mais j'avoue que la proposition de @awecx me semble encore plus pertinente.

padpo sera donc à modifier en fonction de la décision de cette PR

PS : padpo n'utilise pas rst2txt et rst2html, mais analyse directement les chaînes de caractères (sauf pour la partie Grammalecte, ou je génère un texte adapté à Grammalecte pour avoir des messages d'erreur pertinents)

Ping, que décidons nous ?